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1.0  INTRODUCTION 


This  report  presents  the  concept  of  imagery  interoperability,  reviews  the  background 
leading  to  the  establishment  of  the  Imagery  Interoperability  Architecture  (IIA),  describes  in  detail 
this  architecture,  and  discusses  the  military  advantages  to  be  gained  by  applying  the  architecture  to 
a  reconnaissance  program.  The  primary  benefit  of  the  IIA  is  the  value  that  is  added  with  its 
incorporation  into  any  imaging  reconnaissance  system  (using  still  and/or  dynamic  imagery), 
permitting  any  ground  system  to  receive  any  image  at  any  time  regardless  of  the  source. 

Imagery,  one  of  the  highest  quality  sources  of  remotely  collected  intelligence,  is  the  "eyes" 
of  the  commander.  As  a  result  imagery  is  used  to  support  a  wide  range  of  military  applications. 
Hence,  it  is  both  resource  and  mission  effective  to  be  able  to  share  an  image  with  any  military 
function  that  can  use  it.  In  the  traditional  environment,  where  reconnaissance  systems  rely  upon 
hard  copy  film,  sharing  imagery  requires  film  duplication  and  dissemination  by  means  of  physical 
shipping  and/or  handcarrying.  This  process  is  both  resource  intensive  and  time  consuming.  With 
the  advent  of  electro-optical  sensors  and  the  use  of  digital  systems  it  is  now  feasible  to  handle 
imagery  in  electronic  form.  The  image  is  duplicated,  when  needed,  through  the  use  of  a  softcopy 
system  and  disseminated  in  near-real-time  via  transmission  over  communication  lines.  The 
availability  of  high  quality  imagery  in  near-real-time  tremendously  increases  its  value  to  the  military 
commander. 

Digital  electronics  technology  is  the  key  for  improving  the  responsiveness  and  timeliness  of 
the  reconnaissance  intelligence  cycle.  Unfortunately,  the  number  and  diversity  of  reconnaissance 
platforms  and  exploitation  systems  being  deployed  has  grown,  the  cost  of  training  and  logistics 
support  has  increased,  and  there  is  no  guarantee  that  the  analyst  will  be  able  to  access  the  best 
imagery  available.  The  current  philosophy  of  system  development  and  deployment  tightly  couples 
reconnaissance  platforms  to  specific  and  unique  ground  exploitation  facilities.  To  overcome  this 
shortfall  and  ensure  that  the  military  commander  has  timely  access  to  all  appropriate  imagery,  the 
establishment  of  a  common  surface  system  and  interoperability  among  all  digital  imagery  systems 
is  essential. 

In  simplest  terms  image  interoperability  is  the  facility  for  " providing  the  right  image  to  the 
right  user  at  the  right  time."  Interoperability  provides  the  user  the  capability  to  receive,  transport, 
display,  review,  and  exploit  imagery  from  virtually  any  electronic  imagery  sensor  to  any  ground 
system. 

The  Air  Force's  Rome  Laboratory,  recognizing  the  critical  need  for  imagery  intelligence 
interoperability  among  multiple  programs  and  systems,  established  the  Imagery  Interoperability 
Architecture  (IIA)  Program.  The  objective  of  the  IIA  Program  is  to  provide  technical  solutions  for 
establishing  interoperability  across  electronic  imagery  intelligence  systems.  The  Imagery 
Interoperability  Architecture,  the  foundation  of  the  IIA  Program,  addresses  specific  technical  areas 
for  achieving  interoperability  via  standards,  specifications,  and  limited  hardware  and  software 
development.  The  IIA  provides  standards  and  specifications  for  imagery  tape  recorders  and 
cassettes,  data  links,  and  imagery  data  format  architectures.  The  Imagery  Interoperability 
Architecture  is  designed  such  that  interoperability  can  cost-effectively  be  accomplished  not  only  in 
future  reconnaissance  systems  but  in  existing  systems  as  well.  In  establishing  the  means  for 
achieving  electronic  imagery  interoperability,  the  focus  of  the  IIA  Program  has  been  on  the 
interface  between  the  collection  systems  (airborne  systems)  and  the  exploitation  systems  (surface 
systems).  Exhibit  1  illustrates  the  components  of  a  digital  reconnaissance  system  and  the  basic 
elements  of  the  Imagery  Interoperability  Architecture.  Section  3.0  of  this  report  details  the 
elements  of  the  Imagery  Interoperability  Architecture. 
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Exhibit  1 

Image  Interoperability  Architecture 


DATA  STRUCTURES/FORMATS  -  STANDARDS 

•  RECONNAISSANCE  DATA  EXCHANGE  STANDARD 

•  STANAG7023 


TAPE  RECORDERS/CASSETTES  -  STANDARDS 

•  MIL-STD-2179B 

•  STAN  AG  7024 

DATA  LINKS  ■  STANDARDS 

•  COMMON  DATA  UNK  STANDARD 

•  NATO  IMAGE  INTEROPERABLE  DATA  LINK  STUDY 

REFORMATTER  -  HARDWARE/SOFTWARE 


The  availability  of  a  data  link  connecting  the  airborne  and  surface  systems  eliminates  the 
need  for  them  to  be  collocated.  Hence,  the  viewing/exploitation  stations  can  be  deployed  wherever 
the  military  situation  dictates  and  still  receive  timely  data  directly  from  the  remote  collection 
systems.  If  the  data  link  is  implemented  using  the  IIA,  deployment  options  become  more  flexible 
and  make  feasible  the  development  of  an  interoperable  ground  system.  An  interoperable  ground 
system  is  a  family  of  common  components  that  meet  the  specific  requirements  of  all  imagery  user 
organizations  and  agencies,  thus  allowing  the  receipt,  exploitation,  and  dissemination  of  all 
collected  imagery,  regardless  of  the  source,  at  any  single  system. 

The  concept  for  an  interoperable  ground  system  was  developed  by  the  Rome  Laboratory  in 
the  late  1970s.  Then  in  1986  this  concept  was  evaluated  when  Air  Force  Systems  Command 
(AFSC)  conducted  an  F-16  Reconnaissance  Ground  Exploitation  Concept  Validation.  This  activity 
is  commonly  referred  to  as  the  Advanced  Tactical  Air  Reconnaissance  System  (ATARS) 
Validation.  The  ATARS  validation  identified  the  need  to  establish  an  interoperability  architecture 
for  electro-optical  imagery.  From  an  operational  perspective  this  activity  demonstrated  that  the  data 
link  greatly  expands  the  commander's  options  for  flexible  deployment  and  employment  of  image 
exploitation  systems.  In  particular,  it  verified  that  the  traditional  deployment  of  collocating 
airborne  collection  systems  and  exploitation/reporting  systems  is  no  longer  necessary. 

From  a  military  perspective,  the  diversity  of  reconnaissance  assets  that  are  now  available  to 
the  commander  must  be  integrated  into  a  force  structure  similar  to  that  of  weapons  systems  in  order 
to  achieve  the  maximum  benefit  and  efficiency  of  these  powerful  systems.  It  is  becoming  too 
costly  and  inefficient  to  operate  and  manage  reconnaissance  systems  on  a  system  by  system  basis, 
where  each  system  consists  of  a  single-type  collector  and  a  unique  ground  processing  facility 
(termed  a  "stove  pipe").  The  deployment,  integration,  and  application  of  reconnaissance  collection 
assets  must  be  managed  as  a  single  force  and  not  managed  in  such  a  “stove  pipe  manner.” 
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Now  that  digital  technology  allows  for  the  development  of  a  ground  station(s)  capable  of 
supporting  any  and  all  collection  systems,  the  Imagery  Interoperability  Architecture  (IIA)  is 
required  to  achieve  the  interoperability  that  will  allow  the  military  to  evolve  toward  an  optimized 
reconnaissance  force  structure.  The  HA  offers  the  system  developer  and  user  the  flexibility  to  meet 
unique  requirements  while  maintaining  compatibility  with  all  available  reconnaissance  systems 
allowing  timely  access  to  their  imagery  products. 


2.0  BACKGROUND 


Rome  Laboratory  initiated  the  first  system  architecture  for  digital  imagery  system 
interoperability  for  the  Air  Force  through  an  effort  called  the  Common  Architecture  for 
Reconnaissance  Systems  (CARS).  This  architecture  was  developed  in  close  coordination  with  the 
Advanced  Tactical  Air  Reconnaissance  System  (ATARS)  and  the  Joint  Services  Imagery 
Processing  System  (JSIPS)  program  offices,  and  the  U.S.  Navy,  using  the  International  Standard 
Organization’s  Open  Systems  Interconnection  Model  (OSI).  The  OSI  model  provides  the  basis  for 
standards  definitions  for  network  and  point  to  point  communication  protocols,  data  transfer 
formats,  and  computer  systems  environments.  The  OSI  model  has  been  adopted  by  the 
Government,  industry,  and  the  intelligence  community  because  it  promotes  interoperability 
between  systems  and  provides  a  more  integrated  approach  to  evolving  operational  capabilities. 

Under  the  CARS  effort  a  military  standard  was  developed  for  magnetic  tape  recording  and 
playback  of  high  bandwidth  data.  This  standard  was  formally  approved  as  a  MIL-STD-2179A  - 
"Helical  Digital  Recording  Format  for  19mm  Magnetic  Tape  Cassette  Recorder/Reproducer."  This 
standard  followed  industry’s  technology  trends  to  develop  a  high  performance,  high  bandwidth 
tape  recorder  playback  device  using  a  helical  scan  concept.  This  recorder  was  adopted  by  both  the 
JSIPS  and  ATARS  programs. 

Also  under  the  CARS  effort  the  Rome  Laboratory  developed  a  data  structure  standard  for 
digital  imagery  and  imagery  related  data.  This  proposed  standard  is  referred  to  as  the 
Reconnaissance  Data  Exchange  Standard  (RDES).  This  standard  follows  the  OSI  model  and 
defines  the  order  and  structure  of  data  using  headers  for  delineating  various  data  types.  Both  the 
standard  for  data  structures  and  the  high  performance  high  bandwidth  tape  recorder  playback  are 
incorporated  into  the  Joint  Services  Imagery  Processing  System  (JSIPS). 

In  1987,  NATO  conducted  an  electro-optical  image  interoperability  study  for  NATO  Air 
Force  Armaments  Group  (NAFAG)  Air  Group  IV  A/C  224  (Tactical  Aerial  Reconnaissance  in 
Intelligence).  Rome  Laboratory  agreed  to  chair  a  NATO  Interoperability  Design  Study  (NIDS) 
Working  Group.  NIDS  identified  the  best  layer  or  point  of  interface  for  an  imaging  reconnaissance 
system  is  between  a  collector  and  a  surface  or  ground  station.  Exhibit  1  represents  the  top  level 
functions  of  an  aerial  imaging  system.  There  are  only  two  ways  or  methods  of  transporting 
electronic  imagery  from  the  collector  to  a  surface  station:  electrical  transmission  and  electrical 
recording  of  the  data  on  magnetic  tape.  Thus  the  Working  Group  recommended  that  the  following 
transport  standard  be  developed:  STANAG  7024  -  “Imagery  Air  Reconnaissance  Tape  Recorder 
Standard.” 

This  Working  Group  also  recommended  that  a  data  structure  standard  be  developed  so  that 
imagery  and  imagery  related  data  could  be  transported  across  the  above  standard. 
STANAG  7023  -  “Digital  Air  Reconnaissance  Imagery  Data  Architecture”  is  the  resultant 
standard. 
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The  NEDS  also  recommended  that  an  Image  Information  Reformatter  (HR)  be  developed 
for  reformatting  electronic  imagery  from  one  format  to  another  format.  This  development  would 
be  a  cost  effective  interim  solution  for  providing  interoperability  of  electronic  imagery  formats  that 
have  not  adopted  the  data  structures  and  data  transport  standards. 

The  Imagery  Interoperability  Architecture  (IIA)  represents  a  merging  of  the  CARS  and 
NEDS  activities  into  a  single  electronic  architecture  that  is  applicable  to  all  reconnaissance  systems 
regardless  of  country  or  platform.  Exhibit  2  illustrates  the  general  flow  of  activities  that  have  led  to 
the  creation  of  the  IIA. 


Exhibit  2 

Image  Interoperability  Architecture  Legacy 


3.0  IMAGERY  INTEROPERABILITY  ARCHITECTURE 


The  IIA  consists  of  five  major  technical  areas  which  have  been  divided  into  two  categories. 

The  first  category  contains  those  technical  areas  which  require  the  establishment  of  standards  * 

and/or  specifications.  The  second  category  includes  those  areas  which  require  some  hardware 
and/or  software  development. 

The  technical  areas  requiring  the  establishment  of  standards  and/or  specifications  are: 

V  Data  Structures/Formats 

V  Tape  Recorders/Casseues 
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V  DataLrek 

The  technical  areas  requiring  some  hardware/software  development  are: 

V  Imagery  Information  Reformatter  for  non- standard  systems 

V  Processor  adaptable  to  multiple  SAR  systems. 

The  following  sections  address  each  of  the  technical  areas  which  comprise  the  IIA  and 
discuss  the  advantages  gained  by  applying  them  to  a  reconnaissance  program. 

3. 1  DATA  STRUCTURES/FORMATS  STANDARDS 


Within  the  IIA,  the  Reconnaissance  Data  Exchange  Standard  (RDES)  is  the  standard  for 
handling  electronic  imagery  and  imagery  related  data  for  both  still  and  dynamic  imagery.  This 
standard  has  been  submitted  to  NATO  as  a  draft  standard,  referred  to  as  STANAG  7023  -  “Air 
Reconnaissance  Imagery  Data  Architecture.”  The  RDES  is  being  prepared  for  submission  to  the 
Defense  Information  Systems  Agency,  the  executive  agent  for  DoD  information  standards,  for 
consideration  and  approval  as  a  DoD  standard. 

The  aim  of  RDES/STANAG  7023  is  to  provide  a  standard  data  structure  to  be  utilized  in 
the  design  specification  of  the  transport  system  used  for  the  exchange  of  digital  sensor  and 
auxiliary  data  from  airborne  reconnaissance  collection  platforms  (source)  to  surface  receive  stations 
and/or  exploitation  terminals  (destination).  Appropriate  application  of  RDES  also  facilitates  the 
transport  of  imagery  and  imagery  related  data  between  users,  to  and  from  a  user  and  a  storage 
device,  and  many  other  imagery  transport  systems.  This  common  architecture  eases  the 
interoperability  of  reconnaissance  systems  in  DoD  and  among  the  allied  countries.  The 
combination  of  the  data  format  produced  from  this  architecture  with  compatible  data  transfer 
devices  is  the  minimum  requirement  to  achieve  interoperability.  An  example  of  this  basic  data 
structure  defined  in  RDES/STANAG  7023  is  illustrated  in  Exhibit  3. 

The  standard  incorporates  parameters  which  are  the  same  in  structure  and  definition  for 
each  system  and  can  be  used  interchangeably.  Not  all  systems  require  exactly  the  same 
parameters.  Depending  on  system  specifications,  the  utilization  of  parameters  such  as  sensor 
calibration,  data  sensor,  compression  data,  etc.  may  vary  for  each  system.  In  other  words,  one 
system  may  use  a  specific  parameter  while  another  does  not.  This  architecture  has  been  designed 
to  include  such  parameters,  permitting  the  systems  that  need  them  to  access  them. 

An  important  aspect  of  RDES/STANAG  7023  is  the  use  of  a  header  block  to  define  two 
basic  categories  of  data,  sensor  data  and  auxiliary  data.  Sensor  data  is  a  free  format  and  is  handled 
on  a  bit  by  bit  basis.  This  standard  allows  any  sensor  to  sample  its  environment  in  any  number  of 
dimensions.  Auxiliary  data  provides  information  about  the  imagery  both  to  the  surface  processing 
equipment  and  to  personnel  using  the  imagery.  Auxiliary  data  contains  information  about  the 
mission,  platform,  and  sensor  operation  of  that  image  which  can  be  used  when  it  is  received  by  a 
processing  system.  Exhibit  3  illustrates  the  basic  data  structure  of  the  header  block.  Exhibit  4 
provides  an  example  of  the  types  of  information  included  in  the  sensor  data  and  auxiliary  data 
categories. 
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Exhibit  3 

Basic  Data  Structure  of  RDES/STANAG  7023 
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Exhibit  4 

An  Example  of  Data  Types  in  RDES/STANAG  7023 
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The  architecture  is  designed  to  be  compatible  with  th**  OSI  model  for  transporting  digital 
lata  over  communication  systems  and  magnetic  tape  media.  To  simplify  the  management  or 
landling  of  reconnaissance  events  (as  an  example  multiple  missions  on  a  single  platform),  source 
esident  sensor  and  auxiliary  data  have  been  divided  into  manageable  parts  called  blocks.  Each 
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block  is  further  divided  into  files  and  the  standard  allows  for  the  proper  order  of  files  within  a 
block  to  be  defined. 

To  provide  for  transport  flexibility,  files  are  divided  into  records;  records  are  composed  of 
segments;  and  segments  contain  packets.  Each  Packet  consists  of  a  synchronization  field,  a  header 
field  and  a  related  data  field.  Exhibit  5  is  an  illustration  of  a  record. 


Exhibit  5 

An  Example  of  RDES/STANAG  7023  Record 
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The  architecture  has  specifically  been  designed  with  the  capability  to  incorporate  future 
systems  as  they  are  developed.  Data  areas  have  been  reserved  for  parameters  which  are  yet  to  be 
defined.  The  architecture  also  provides  the  ability  to  describe  multiple  missions  as  they  are  being 
recorded.  The  mission  data  block  can  be  repeated  throughout  the  mission  and  the  rate  of  repetition 
is  flexible,  depending  upon  the  collection  tasking.  In  this  respect,  the  standard  has  been 
characterized  as  a  “living  standard”  which  can  adjust  and  continually  grow  with  the  addition  of  new 
systems.  Exhibit  6  illustrates  the  growth  potential  of  the  standard. 

Exhibit  6 

RDES/STANAG  7023  Growth  Potential 
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3.1.1  HEADER  BLOCK 


An  in-depth  view  of  the  header  block  demonstrates  the  flexibility  that  is  inherent  in 
RDES/STANAG  7023.  The  sync  word  is  10  bytes  with  the  remaining  22  bytes  distributed  as 
illustrated  in  Exhibit  7. 


Exhibit  7 

Header  Data  Format 
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V  Synchronization  Type  —  The  first  field  in  the  header,  the  synchronization  (sync) 
type,  is  used  to  identify  each  type  of  sync  which  may  be  required  when  transmitting 
sensor  data.  The  sync  type  field  precludes  having  different  sync  codes  to  identify  the 
various  types  of  sync.  The  different  types  of  sync  used  in  this  standard,  and  their  order 
of  precedence  are:  block,  frame,  field,  swath  and  line.  An  order  of  precedence  is 
necessary  since  different  types  of  sync  will  be  required  to  occur  at  a  particular  boundary 
in  the  RDES  data.  If  a  block  sync  occurs,  it  implies  that  all  the  syncs  following  will 
occur  as  well,  and  so  on  through  the  order. 

V  Data  Source  —  This  field  describes  the  source  from  which  a  data  file  originates.  For 
example,  sensor  1,  sensor  2,  platform,  mission,  etc.  are  specific  data  sources. 

V  Data  File  Address  —  This  field  further  breaks  down  the  address  of  the  individual 
fields  associated  with  each  data  source. 

V  Flags  —  Eight  separate  two  state  flags  are  included  in  the  header.  The  first  flag 
indicates  which  auxiliary  data  blocks  have  been  updated.  The  second  flag  indicates 
whether  or  not  the  data  has  been  compressed.  The  last  six  flags  are  currently  reserved 
for  future  use. 

V  Length  of  block  —  This  field  contains  the  length  of  the  block  from  which  the 
associated  data  field  originated.  The  length  is  defined  as  an  integer  number  of  data  files 
per  block.  This  allows  the  data  files  to  be  variable  length  and  thereby  a  more  efficient 
data  record. 
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V  Block  file  number  —  This  field  indicates  the  order  of  the  associated  data  file 
within  the  block  from  which  it  originated.  It  is  used  for  source  block  replication  at  the 
destination  system.  This  allows  more  efficient  use  of  the  data  collected. 

V  Event  number  —  The  event  number  is  sequentially  assigned  to  each  marked  event 
throughout  any  record.  Throughout  the  course  of  a  reconnaissance  mission  several 
significant  events  can  be  identified  to  permit  queuing  or  sorting  of  sensor  data. 

V  Event  type  —  The  event  type  field  identifies  the  type  of  the  marked  event 

V  Data  file  size  —  This  field  contains  an  integer  number  representing  the  number  of 
words  contained  in  the  associated  auxiliary  data  file,  or  the  number  of  samples 
contained  in  the  associated  sensor  file.  This  allows  the  data  files  to  be  variable  length 
and  thereby  a  more  efficient  data  record. 

V  Image  Segment  Number  —  This  field  identifies  the  image  segment.  Initially  set  at 
one,  it  increases  by  increments  of  1  for  each  new  acquisition. 

V  Time  tag  —  This  field  permits  relative  time  correlation  of  different  events.  The  time 
indicates  the  point  at  which  the  contents  of  the  associated  data  file  were  recorded.  The 
time  tag  is  a  32  bit  increment  periodic  count  which  commences  at  the  start  of  a  record 
with  a  value  of  0.  This  field  becomes  very  important  when  it  is  necessary  to  sort  out 
different  reconnaissance  images  of  the  same  area.  This  will  allow  developing  a  time 
sequence  of  images  of  the  same  geographical  area,  but  were  collected  by  different 
reconnaissance  systems. 

V  Reserved  —  This  field  is  reserved  for  future  growth.  This  reserved  field  is  very 
large  and  can  be  used  for  different  applications  that  have  not  been  considered  in  the 
development  of  this  data  structure. 

V  Checksum  —  The  checksum  is  the  complement  of  modulo  256  sum  used  to  verify 
the  validity  or  integrity  of  data  in  the  header. 


3.1.2  DATAFILES 


RDES/STANAG  7023  has  two  general  categories  of  data  files:  sensor  data  and  auxiliary 

data. 


3. 1.2.1  Sensor  Data  Files 

Sensor  data  is  the  imagery  collected  from  the  reconnaissance  sensors.  Sensor  data  is 
classified  by  the  type  of  data  generated  by  the  sensor  system  such  as  IR,  EO,  and  SAR.  Sensor 
data  files  may  be  variable  in  length.  The  length  of  the  sensor  data  file  is  identified  in  the  header 
block  preceding  the  file.  The  specific  data  structure  of  sensor  data  file  is  sensor  dependent  and  the 
structure  is  identified  in  the  sensor  parametric  auxiliary  data  file.  There  can  be  up  to  65,000 
different  sensor  data  files.  These  can  be  either  different  sensors  or  different  collection  systems. 
Thus  there  can  be  slightly  more  than  65,000  different  reconnaissance  systems  accommodated  by 
this  data  structure.  The  sensor  data  can  be  of  any  pixel  depth  and  can  be  any  number  of  pixels  per 
frame  or  per  mission  of  line  scan  system.  The  format  can  accommodate  the  handling  of 
unprocessed  (phase  history)  Synthetic  Aperture  Radar  (SAR)  and  can  even  be  used  to  record 
nonimaging  sensor  data  such  as  SIGINT  sensor  data. 
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3. 1.2.2  Auxiliary  Data  Files 


Auxiliary  data  provides  the  information  necessary  for  the  imagery  analyst  to  derive 
intelligence  information  from  the  imagery.  It  also  provides  the  information  required  by  the  surface 
exploitation  system  to  process  raw  imagery  data  into  a  form  which  is  usable  by  the  imagery 
analyst.  Auxiliary  data  is  divided  into  categories  associated  with  the  source  of  the  information. 
Auxiliary  data  files  may  be  variable  in  length.  The  length  of  the  auxiliary  data  file  is  identified  in 
the  header  block  preceding  the  file.  Auxiliary  data  can  be  used  by  a  reconnaissance  system  in 
handling  different  reconnaissance  sensor  configurations  and  through  acceptance  of  the  standard  can 
process  non-reconnaissance  imagery.  The  RDES/STANAG  7023  has  defined  the  following 
categories  of  auxiliary  data  which  comprise  the  auxiliary  data  files: 

3.1. 2.2.1  Format  description  data  files.  The  format  description  data  files  provide 
descriptive  information  about  the  format,  such  as  time  tag  parameters.  The  data  format  is  also 
assigned  a  version  number  which  is  used  for  identification  purposes. 

3.1. 2.2.2  Fill  data  files.  The  fill  data  files  consist  of  predefined  byte  sequences  inserted 
into  the  imagery  and  its  auxiliary  data  so  that  data  rates  are  equalized. 

3.1 .2.2.3  Mission  data  files.  The  mission  data  files  describe  the  mission  correlating  to  the 
sensor  data.  The  mission  data  files  contain  three  categories  of  information:  administrative  data 
(i.e.  mission  number,  requester  identification  air  tasking  order  data,  security  classification,  etc.), 
target  search  data  (i.e.  target  type,  location,  basic  encyclopedia  numbers,  etc.),  and  remarks.  Only 
those  mission  data  files  required  to  describe  the  mission  need  be  used. 

Mission  data  is  one  of  the  unique  features  of  RDES/STANAG  7023,  in  that  the  information 
contained  in  this  file  provides  any  image  exploitation  system  with  the  information  to  fully  exploit 
any  image.  This  image  exploitation  interoperability  allows  a  collector  to  data  link  imagery  to  any 
exploitation  system  at  any  time.  In  times  of  hostilities  it  is  not  always  possible  to  complete  a 
reconnaissance  mission  as  planned,  the  incorporation  of  the  mission  data  files  assures  that  collected 
imagery  can  be  transmitted  to  a  ground  system  even  if  the  mission  is  aborted. 

3. 1.2.2. 4  _ Platform  data  files.  Platform  data  files  provide  parametric  information 

describing  the  platform  on  which  the  sensors  are  mounted.  This  file  was  derived  from  NATO 
STANAG  3837 AA. 

This  file  can  easily  accommodate  navigation  and  air  data  computer  systems  that  are  not 
compatible  with  this  particular  format.  To  handle  these  unique  systems,  another  type  of  platform 
data  file  can  be  built  and  incorporated  into  the  RDES/STANAG  7023.  Incorporation  of  this  data 
file  structure  provides  the  reconnaissance  program  automatic  compatibility  with  all  of  the  other 
DoD  and  NATO  standards  for  this  data. 

3.1. 2.2.5  Event/index  data  files.  The  event/index  data  files  function  as  a  directory  used  to 
cue  significant  events  that  occurred  during  a  mission  on  the  transport  media.  These  data  files 
contain  a  chronological  record  of  the  events.  Events  are  categorized  as  either  programmed  or 
manual. 

This  is  a  very  useful  data  file  for  a  reconnaissance  ground  station  and  provides  an  easy 
method  to  rapidly  sort  through  large  volumes  of  mission  data  and  sort  between  missions  to  locate 
specific  events. 


3.1.2i2.6  Sensor  parametric  data  files.  The  sensor  parametric  data  files  describe  the 
sensor  data  format  directly  through  the  provision  of  parameters,  or  indirectly  through  a  table  of 
tabular  parameters.  Currently,  there  are  eight  types  of  sensor  parametric  data:  1)  sensor 
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identification,  2)  sensor  calibration,  3)  sensor  data  compression,  4)  sensor  sample  description,  5) 
sensor  sample  element  description,  6)  sensor  operating  mode,  7)  sensor  processing,  and  8)  sensor 
mapping.  The  sensor  transfer  order  data,  sampling  order  data,  sample  timing  data,  and  sensor 
sample  coordinate  data  files  are  tables  used  to  geometrically  model  any  one-to-one  sensors.  This 
data  file  identifies  the  unique  characteristics  of  each  sensor. 

Selected  sensor  parametric  files  have  already  been  defined  and  these  can  be  used  by  the 
reconnaissance  program  as  a  guide  to  developing  specific  files  for  unique  reconnaissance  sensors. 

3.1. 2.2.7  Audio  data  files.  Audio  data  enables  the  reconnaissance  aircrew  on  the 
collection  platform  to  provide  an  audio  narrative  of  mission  events  to  the  imagery  analyst  located  in 
the  ground  station.  To  accommodate  the  various  and  diverse  formats,  audio  data  is  formatted  as 
one-dimensional  sensor  data  and  is  described  in  the  sensor  parametric  data  files. 


3. 1 .3  ADVANTAGES  OF  APPLYING  THE  STANDARD  DATA  STRUCTURES/FORMATS 
TO  A  RECONNAISSANCE  PROGRAM 


An  example  of  how  RDES/STANAG  7023  might  be  used  in  a  reconnaissance  mission  is 
illustrated  in  Exhibit  8.  This  architecture  allows  multiple  data  types  to  be  recorded  simultaneously 
during  a  mission.  The  data  structures  and  the  organization  of  the  data  structures  allows  for  the 
multiple,  simultaneously  recorded  data  (sensor,  platform,  inflight  pilot  reports,  etc.)  to  be 
transported  to  multiple  ground  stations  where  the  entire  mission  can  be  reconstructed  with  respect 
to  time  for  viewing  and  or  exploitation.  The  information  contained  in  the  mission  data  file  allow 
receipt,  exploitation,  and  dissemination  of  imagery  by  a  non-tasked  system  (s).  This  exploitation 
interoperability  (any  system  being  able  to  satisfy  the  mission  requirements  of  any  collected  data)  is 
a  unique  feature  of  the  IIA  and  for  the  first  time  ensures  that  data  collected  can  be  exploited  despite 
any  disruptions  to  the  originally  planned  mission.  This  benefit  of  interoperability  provides  a 
functionality  that  is  critical  in  times  of  hostility  where  the  expected  availability  of  scheduled  or 
dedicated  exploitation  resources  may  change  significantly  from  prior  plans. 

Exhibit  8 

Example  of  a  Reconnaissance  Mission  with  Multiple  Recordings 
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Both  RDES  and  STANAG  7023  have  more  than  sufficient  capacity  for  accommodating  the 
unique  needs  of  any  reconnaissance  system.  The  flexibility  of  the  header  structure  and  its  contents 
allows  it  to  accommodate  any  specific  reconnaissance  needs.  One  of  the  Sensor  Data  File  formats 
has" already  been  specifically  designed  to  address  magnetic  tape  recording  formats  for  conventional 
TV  signals  conforming  to  common  industry  TV  video  transmission  standards  ESD  170  and  ESD 
343.  The  Auxiliary  Data  Files  currently  meet  all  of  the  reconnaissance  information  needs  with  the 
implementation  of  the  Sensor  Parametric  Data,  Mission  Data,  and  Platform  Data  Files.  The 
Event/Index  Data  File  can  be  used  to  facilitate  the  ground  system's  ability  to  search  and  retrieve 
from  recorded  imagery. 

The  reconnaissance  program  accrues  many  advantages  by  incorporating  the  IIA  data 
structures/formats  standards. 

V  Common  data  structures  and  formats  for  all  reconnaissance  systems  are  ensured. 

V  Interoperability  and  commonality  across  all  reconnaissance  systems  is  allowed. 

V  Interoperability  and  commonality  with  future  NATO  reconnaissance  systems  is 
permitted. 

V  All  the  benefits  and  advancements  achieved  by  the  IIA  Program  are  inherited. 


3.2  HELICAL  RECORDER/CASSETTE  STANDARDS 


The  magnetic  tape  recorder  and  cassette  can  be  used  for  on-board  recording  of  imagery  and 
imagery  related  data  and  subsequent  ground  based  playback,  as  well  as  being  used  to  transport 
imagery  and  imagery  related  data  between  users.  The  IIA  Helical  Recorder/Cassette  Standard 
specifies  physical  cassette  dimensions,  tape  size,  materials  and  principal  properties,  tape  record 
locations,  dimensions  and  orientation,  a  helical  recording  method  and  specifications,  and  the 
physical  and  electronic  recorder-cassette  interface  tape  cassettes.  The  IIA  Helical 
Recorder/Cassette  Standard  provides  the  physical  means  to  exchange  digital  data  among 
reconnaissance  systems  and  components.  This  standard  also  specifies  analog  formats  and 
prescribes  a  single  (serial)  digital  bit  stream  recorded  and/or  reproduced  proportional  to  the  input 
clock  rate.  It  accommodates  data  rates  from  10  to  480  megabits  per  second.  It  allows  changes 
within  data  rates  while  maintaining  a  specific  packing  density  and  format  at  any  speed.  Tape 
speeds  are  variable  and  independent  to  input  data  rates.  This  standard  specifies  that  data  be 
recorded  in  a  helical-scan  format,  with  tracks  of  supporting  data  recorded  in  a  longitudinal  format. 
The  longitudinal  tracks  are  used  for  annotation  data,  servo  control,  and  time  code  or  voice 
respectively.  Exhibit  9  illustrates  the  format  characteristics  of  this  standard. 

3.2. 1  MIL- STD-2 1 79B  -  "HELICAL  DIGITAL  RECORDING  FORMAT  FOR  19MM 
MAGNETIC  TAPE  CASSETTE  RECORDER/REPRODUCER” 


This  helical  digital  recorder  standard  was  developed  by  the  Navy  for  the  anti-submarine 
warfare  systems  and  uses  the  TV  production  industry's  standard  D-l  recording  tape. 
MIL-STD-2179B  is  an  updated  revision  of  MIL-STD-2179A  reflecting  current  technology. 
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Exhibit  9 

Helical  Recoider/Cassette  Standard 


REFERENCE; 


3.2.2  STANAG  7024  -  "IMAGERY  AIR  RECONNAISSANCE  TAPE  RECORDER 
STANDARD" 


This  helical  digital  recorder  standard  addresses  the  digital  and  analog  recording  of 
reconnaissance  imagery  on  the  following  media: 

V  8  mm  width  tape  for  recording  both  analog  and  digital  data. 

V  12.65  mm  width  tape  for  recording  analog  data. 

The  incorporation  of  the  MIL-STD-2179  for  the  19  mm  cassette  tape  for  recording  digital 
data  has  been  included  in  STANAG  7024  as  a  "to  be  added"  option  based  upon  further  test  and 
evaluation. 


3.2.3  ADVANTAGES  OF  APPLYING  THE  RECORDER/CASSETTE  STANDARD  TO  A 
RECONNAISSANCE  PROGRAM 


The  IIA  Recorder/Cassette  standards,  MIL-STD-2179B  and  STANAG  7024,  have  a  full 
range  of  recording  and  playback  capabilities  that  are  directly  applicable  to  the  reconnaissance 
program.  This  relevance  is  demonstrated  by  the  tape/cassette  sizes  and  signal  recording  types 
addressed  by  these  standards: 

V  8  mm  width  tape  for  recording  both  analog  and  digital  data. 

V  12.65  mm  width  tape  for  recording  analog  data. 

V  19  mm  cassette  tape  for  recording  digital  data 

All  of  the  above  IIA  Recorder/Cassette  standards  can  meet  a  large  majority  of  the  needs  of  a 
reconnaissance  program.  The  advantages  the  reconnaissance  program  accrues  by  incorporating  the 
IIA  Recorder/Cassette  standards  are: 
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V  The  use  of  common  recorders/cassettes  for  all  reconnaissance  systems  is  ensured. 

V  Interoperability  of  imagery  across  all  reconnaissance  systems  is  allowed. 

V  Interoperability  of  imagery  with  future  NATO  reconnaissance  systems  is  permitted. 

V  All  the  benefits  and  advancements  achieved  by  the  IIA  Program  are  inherited. 


3.3  DATA  LINK  STANDARD 


Duane  P.  Andrews,  the  Assistant  Secretary  of  Defense  for  C3I  stated,  in  a  December  13, 
1991  memorandum  to  the  Secretaries  of  the  Military  Departments,  the  Directors  of  the  Defense 
Agencies,  and  the  Director  of  the  Joint  Staff: 

"The  Department  of  Defense  has  an  increasing  number  of  imagery 
and  signals  intelligence  collection  systems  which  use  or  require  a 
high-capacity,  secure  jam-resistant  data  link  to  connect  the  airborne 
sensor  payloads  to  the  land  or  shipboard  control  and  processing 
segments.  Common  interfaces  between  these  systems  within  the 
respective  discipline  is  essential  for  interoperability,  and  they 
provide  the  opportunity  for  significant  cost-savings  in  development, 
procurement  and  support  of  airborne  and  ground  systems’’ 

There  are  two  separate  efforts  under  the  Imagery  Interoperability  Architecture  Program  to 
develop  a  data  link  standard  for  electronic  imagery  as  directed  by  Mr.  Andrews: 

V  USAF  effort  for  a  Common  Data  Link,  which  is  the  DoD  directed  standard  program 

V  NATO  Imagery  Interoperable  Data  Link  Study  (NIIDLS) 

The  goal  of  both  of  these  efforts  is  to  create  data  link  interoperability  through  a  family  of 
equipments  that  provide  full  service  Command,  Control,  and  Communications  (C3)  for  all 
intelligence/reconnaissance  assets.  The  concept  of  an  interoperable  data  link  is  illustrated  in 
Exhibit  10. 

Currently,  digital  or  electronic  imagery  can  be  transmitted  via  data  link  to  surface  facilities 
accelerating  the  delivery  and  exploitation  of  priority  imagery.  As  a  first  step  in  achieving  data  link 
interoperability,  a  model  was  developed  based  upon  the  philosophy  and  standards  of  the  Open 
Systems  Interconnection  (OSI)  which  is  addressing  the  issue  of  interoperability  between  computer 
systems.  The  Interoperable  Data  Link  Model  (IDL)  is  a  layered  model  where: 

V  The  highest  level  interacts  with  the  outside  world 

V  Equivalent  layers  must  correspond 

V  Each  layer  in  a  single  system  communicates  only  with  those  layers  directly  above  or 
below  it 
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V  The  lowest  layer,  the  physical  layer,  contains  the  data  link  and  data  link  medium  or 
channel. 

Exhibit  10 

Interoperable  Data  Link 
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The  Interoperable  Data  Link  Model,  illustrated  in  Exhibit  11,  is  the  functional  design  being 
used  by  both  the  US  Control  Data  Link  Program  and  the  NATO  Imagery  Interoperable  Data  Link 
Study  (NIIDLS). 

Exhibit  11 

Interoperable  Data  Link  Model 
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From  a  technical  perspective,  data  link  interoperability  can  be  achieved  through  the 
following  steps: 

V  Specify  and  direct  interoperability  through  a  series  of  A-level  segment  documents, 
program  funding  assessments,  and  the  creation  of  a  high  level  government  program. 

V  Create  a  family  of  common  modules  that  would  adequately  implement  the  specified 
standard.  These  common  modules  will  be  sufficiently  flexible,  in  terms  of  fit  and 
functionality,  to  be  usable  on  a  variety  of  platforms  and  operation  environments. 

V  Create  user  documentation  so  that  a  true  non-vendor  specific  implementation  is 
achievable. 

The  following  sections  describe  the  US  and  the  NATO  data  link  programs  and  discuss  how 
each  is  addressing  the  issue  of  interoperability. 


3.3.1  U.S.  COMMON  DATA  LINK  (CDL) 


In  the  mid  1970s  it  became  apparent  to  top  DoD  managers  in  the  Office  of  the  Secretary  of 
Defense/Assistant  Secretary  of  Defense  for  C3I  that  mission  requirements  and  objectives 
established  by  the  Joint  Chiefs  of  Staff  (JCS)  and  theater  Commanders  in  Chiefs  (CINCs)  could 
only  be  fulfilled  if  interoperability  among  intelligence  sources  could  be  achieved.  Studies 
performed  by  OSD/C3I  concluded  that  data  link  interoperability  was  the  key.  Additional  activity 
concluded  that  a  development  of  data  link  standards  with  implementing  common  modules  was  the 
favored  approach. 

In  1988,  Congress  mandated  in  the  Defense  Authorization  to  the  Department  of  Defense 
(DoD),  that  the  data  link  developments  should  be  consolidated  under  the  guidance  of  a  Common 
Data  Link  program  office.  The  CDL  program  office  has  the  authority  to  establish  standards  and 
interfaces;  control  the  configuration  of  common  modules;  and  develop  additional  technology  as 
required. 

The  ultimate  goal  of  the  CDL  program  is  to  define  a  data  link  capability  to  support  C3  by 
providing  the  following: 

V  Specifications  for  sensor  control  interfaces. 

\  Specifications  for  platform  interfaces. 

V  Ensuring  that  the  above  interfaces  are  non  -platform  and  non-sensor  specific. 

V  Ensuring  that  the  C3  interfaces  are  compatible  with  any  defined  user. 

V  C3  interfaces  that  are  adaptable  from  both  a  technology  and  threat  perspective. 

This  C3  interoperability  is  achieved  by  providing  specifications  for  electrical,  mechanical 
and  performance  requirements  through  an  end-to-end  system  which  could  be  implemented  using 
defined  hardware  and  software  specific  functionality.  The  hardware  is  known  as  the  CDL 
Common  Modules.  The  subsystem  specifies  communication  paths,  path  characteristics,  wave 
forms,  and  baseband  information.  A  similar  set  of  specifications  is  also  provided  for  the  data  link 
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control  links.  A  draft  specification  (Type  A  Specification  for  the  Common  Data  Link  Segment  - 
Class  1,  Specification  Number  7681990,  dated  August  1989)  has  been  prepared  and  a  revision  will 
soon  be  released. 

The  CDL  will  have  completed  Full  Scale  Engineering  Development  (FSED)  in  late  1991. 
The  CDL  has  developed  all  the  standards  required  to  implement  the  IDL  Model  (see  Exhibit  11). 
The  CDL  has  also  produced  a  family  of  digital,  analog,  radio  frequency,  and  antenna  modules  that 
can  implement  the  basic  Interoperable  Data  Link  (IDL)  waveform  and  provide  an  expansion 
capability  to  implement  additional  waveforms  as  projected  by  the  technology  insertion  plans.  The 
CDL  has  been  determined  to  meet  the  existing  and  planned  needs  for  both  interoperability  and 
commonality. 

The  application  of  the  CDL  common  modules  and  assets  provides  the  military  commander 
the  capability  to  establish  both  a  Global  and  Theater  communications  capability  to  control  and 
disseminate  real  time  products  from  Tactical  and  National  reconnaissance  platform  products  which 
yield  multi-spectral  and  multi-signal  information  anywhere  in  the  world. 


3.3.2  NATO  IMAGERY  INTEROPERABLE  DATA  LINK  STUDY  (NIIDLS) 


A  NIIDLS  Ad  Hoc  Working  Group  was  established  in  April  1990  by  the  NATO  Air  Force 
Armament  Group  (NAFAG)  Air  Group  IV  “Tactical  Air  Reconnaissance  Intelligence”  (AC/244). 
The  origin  of  the  NIIDL  Ad  Hoc  Working  Group  has  its  roots  in  a  previous  study,  the  NATO 
Interoperability  Design  Study  (NIDS).  NIDS  was  completed  in  1988  and  provided  the  foundation 
for  the  implementation  of  a  NATO  Imagery  Interoperability  Architecture. 

The  NATO  Interoperability  Imagery  Data  Link  Study  (NIIDLS)  Ad  Hoc  Working  Group 
served  as  an  excellent  forum  for  the  international  exchange  of  diverse  viewpoints  and  created  an 
acceptable  methodology  for  technical  resolution  of  issues.  This  Working  Group  was  supported  by 
an  Industrial  Support  Group  (ISG)  whose  responsibilities  were  to  provide  technical  guidance  and 
perform  the  analysis  of  the  data  base  and  assess  the  results  in  an  advisory  capacity  to  the  NIIDL  Ad 
Hoc  Working  Group.  The  following  suggestions  are  the  consensus  of  the  participating  members 
in  the  NIIDL  Study  Ad  Hoc  Working  Group  and  were  presented  to  NAFAG  Air  Group  IV  with 
recommendations  for  their  consideration  and  action. 

V  NATO  data  link  interoperability  is  achievable  but  no  existing  data  link  currently 
available  or  being  planned  supports  all  NATO  interoperability  system(s)/data  link(s) 
requirements. 

V  Three  classes  of  data  links  are  sufficient  to  span  the  NATO  functional,  performance, 
and  operational  requirements.  They  are: 

•  Class  1  -  Analog  Links 

•  Class  2  -  Point  to  Point  Digital  Links 

•  Class  3  -  Broadcast  Digital  Links 

V  Interoperability  is  achievable  through  the  development  of  specific  interface  standards 
for  future  systems.  The  standards  should  adopt  the  proposed  interoperable  data  link 
model  which  is  presented  in  Exhibit  11. 

a/  In  the  short  term  the  burden  of  interoperability  implementation  should  be  placed  on  the 
ground  data  link  segments  rather  than  the  airborne  data  link  segments.  The  study 
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proposes  several  joint  NATO  R&D  programs  that  would  allow  the  ground  segments  to 
handle  the  problems. 

V  Any  interoperable  data  link  must  incorporate  the  NATO  Image  Interoperability 
Architecture  standards: 

•  STANAG  7023  -  “Air  Reconnaissance  Imagery  Data  Architecture” 

•  STANAG  7024  -  “Imagery  Air  Reconnaissance  Tape  Recorder  Standard” 

V  The  establishment  of  a  NATO  cooperative  development  program  for  a  flexible  data 
receive/transmit  data  link  subsystem  and  a  common  sensor  signal  processor  subsystem 
would  increase  the  ability  to  achieve  operational  interoperability  in  the  near  term.  An 
image  information  reformatter  is  still  necessary  to  achieve  near  term  interoperability. 


3.3.3  ADVANTAGES  OF  APPLYING  THE  HA  DATA  LINK  STANDARDS  TO  A 
RECONNAISSANCE  PROGRAM 


The  IIA  Data  Link  efforts  are  focused  on  minimizing  the  expenditure  of  resources  for  data 
links  within  both  the  U.S  and  NATO  forces.  It  is  anticipated  that  the  IIA  effort  will  follow  the 
United  States  Common  Data  Link  philosophy.  Data  link  interoperability  is  established  through  a 
family  of  equipments  that  provide  full  service  Command,  Control,  and  Communications  (C^)  for 
intelligence/reconnaissance  assets  controlled  by  the  DoD.  The  CDL  program  has  three  objectives 
that  are  directly  compatible  with  a  reconnaissance  program,  they  are: 

V  Establish  a  family  of  standards  and  specifications  that  follow  the  International  Systems  < 

Organization  (ISO)  Open  Systems  Interconnection  (OSI )  model  philosophy  tailored  for 

data  link  C3  applications. 

V  Develop  a  family  of  common  modules  that  can  be  used  by  the  various  services  and  their 
program  offices  to  implement  mission  specific  hardware/software  functions  and  will 
assure  compliance  with  the  interoperability  standards  and  specifications.  These 
modules  are  to  be  available  from  multi-vendor  sources. 

V  Devise  a  technology  insertion  plan  for  C3  data  links  that  will  enhance  the  integrated  C3 
connectivity  and  follow  the  mission  needs  and  objectives  of  DoD  and  NATO. 

The  advantages  accrued  by  a  reconnaissance  program  through  the  incorporation  of  the  IIA 
Data  Link  standards  are: 

V  Availability  of  a  Common  Data  Link  for  the  reconnaissance  program  that  is  also 
common  to  other  reconnaissance  surveillance  systems  both  U.S.  and  NATO. 

V  Data  link  interoperability  and  commonality  across  all  reconnaissance  programs  is 
facilitated. 

V  The  benefits  of  the  IIA  program  are  shared. 
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3.4  IMAGERY  INFORMATION  REFORMATTER  (HR) 


Interoperability  cannot  be  achieved  through  format  standards  and  specifications  alone. 
Existing  systems  are  not  standard,  and  to  modify  them  is  simply  not  cost  effective.  Recognizing 
that  there  is  a  need  to  address  non-standard  systems,  now  and  possibly  in  the  future,  die  IIA 
includes  the  development  of  a  reformatter  to  provide  interoperability  of  existing  electro-optical 
imagery  and  auxiliary  data  from  one  format  to  another  in  near-real-time.  A  top  level  schematic  of 
this  system  is  illustrated  in  Exhibit  12.  The  HR  performs  three  basic  reformatting  functions: 

V  Reformats  any  unique  senses'  image  format  into  a  single  standard  (IIA)  format. 

V  Reformats  a  single  standard  (IIA)  format  into  any  unique  sensor  format. 

V  Allows  the  interchange  of  sensor  imagery  information  and  auxiliary  data  between  two 
different  unique  imagery  information  systems. 

These  two  reformatting  capabilities  will  reduce  subsequent  image  processing  system 
development  costs  since  reformatting  diverse  sensor  formats  to  a  single  standard  reduces  image 
hardware  costs,  and  eliminates  the  cost  of  modifying  each  algorithm  for  every  image  format. 
STANAG  7023  has  been  selected  as  the  single  standard  format,  because  it  can  accommodate  any 
sensor  format  and  preserves  the  integrity  of  any  sensor. 

Exhibit  12 

Image  Information  Reformatter  Schematic 
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3.4. 1  IMAGERY  INFORMATION  REFORMATTER  (DR)  FUNCTIONALITY 


A  reformatting  scenario  would  begin  with  acceptance  of  the  uniquely  formatted  imagery 
ind  auxiliary  information  from  the  source  transport  device  by  the  I/O  interface  module.  The  data  is 
hen  converted  into  formats  compatible  with  the  I/O  busses  Interface  Control  Document  (ICD). 
rhis  conversion  requires  numerous  functions  including  analog-to-digital  conversion  (or  vice 
/ersa),  multiplexing/demultiplexing,  data  rate  matching,  compression/decompression,  filtering, 
;tc.  The  I/O  bus  transports  the  source  data  to  the  core  where  software  format  configuration  files 
ire  programmed  to  recognize  the  information  source.  Once  the  source  data  is  identified,  the  core 
further  reformats  the  data  into  a  standard  format  ( STANAG  7023  has  been  selected  based  upon  its 
robustness).  At  this  point,  any  additional  auxiliary  data  required  by  the  destination  format/system 
is  automatically  inserted.  (Manual  insertion  is  also  available.)  Data  is  then  reformatted  from  the 
internal  STANAG  7023  to  an  ICD  compatible  format  via  a  bus  to  the  I/O  interface  module.  The 
I/O  interface  module,  which  is  connected  to  the  destination  transport  device  (or  directly  to  a  host 
system  imagery  processor),  then  performs  the  necessary  functions  to  convert  the  data  to  the 
specified  destination  format. 


3.4.2  IMAGERY  INFORMATION  REFORMATTER  FUNCTIONS 


The  Image  Information  Reformatter  has  several  valuable  functions  in  addition  to  the 
idvantages  discussed  above.  Some  of  these  reformatter  functions  are: 

V  Media  Conversion.  The  reformatter  can  be  used  to  reformat  sensor  data  from  one 
media  to  another.  Such  as  placing  imagery  on  optical  disc,  or  on  magnetic  disc,  or 
converting  8  mm  magnetic  tape  to  12.65  mm  magnetic  tape,  etc. 

V  Duplication.  This  is  similar  to  media  conversion,  however,  the  reformatter  has  the 
capacity  to  make  multiple  copies  simultaneously.  The  number  of  simultaneous  copies 
is  directly  dependent  upon  the  speed  of  the  slowest  input  /output  device  being  used. 

V  Front  End  Processor.  The  reformatter  can  serve  as  a  front  end  processor  for  any 
image  processing  system  needing  to  reformat  all  input  data  into  an  internal  processing 
format.  The  front  end  processing  function  also  supports  converting  any  sensor  data 
format  into  any  secondary  dissemination  format.  This  functionality  assures  that  any 
sensor  product  can  be  disseminated  to  any  user  employing  existing  formats  and 
communication  systems. 

V  Sensor  Data  Filter.  The  reformatter  can  be  used  to  filter  out  selected  data  as  it  is 
being  input  into  the  reformatter  system.  This  can  serve  as  a  data  reduction  or  speed 
reduction  process.  This  function  can  also  be  used  to  downgrade  selected  imagery. 


3.4.3  ADVANTAGES  OF  THE  IMAGERY  INFORMATION  REFORMATTER  (HR)  TO  A 
RECONNAISSANCE  PROGRAM 


The  Image  Information  Reformatter  reduces  the  cost  and  time  to  accommodate  a  new 
source  or  destination  format.  With  the  integration  of  the  HR  in  any  reconnaissance  system,  the 
iddition  of  a  new  source  or  destination  would  require  only  the  one  time  development  of  protocols 
o  and  from  STANAG  7023  -  "Air  Reconnaissance  Imagery  Data  Architecture"  in  order  to  transmit 
he  data.  There  is  no  need  to  develop  multiple  direct  conversion  methods  from  every  source  format 
o  every  destination  format.  All  that  is  needed  is  a  method  to  convert  the  source  format  to  the 
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STANAG  7023,  and/or  from  STANAG  7023  to  a  new  destination  format.  Thus,  once  in 
STANAG  7023,  data  from  any  unique  sensor  can  be  reformatted  to  any  specific  destination 
system/device.  Without  the  reformatter  an  additional  unique  interface  must  be  developed  for  each 
destination  every  time  a  new  source  or  a  new  destination  is  added  to  the  configuration. 

The  IIA  Image  Information  Reformatter  is  directly  and  immediately  applicable  to  a 
reconnaissance  program  by  allowing  the  reconnaissance  program  to  be  interoperable  with  any 
other  reconnaissance/exploitation/viewing  system. 

The  following  benefits  are  attained  by  a  reconnaissance  program  when  the  IIA  Image 
Information  Reformatter  is  incorporated: 

V  Reconnaissance  systems  are  able  to  receive  and  process  reconnaissance/surveillance 
data  collected  by  other  systems  with  a  minimum  of  system  modifications. 

V  Imagery  interoperability  and  commonality  is  achieved  across  all  reconnaissance 
systems. 

V  The  benefits  of  the  IIA  program  are  shared  with  all  the  systems  using  the  IIR. 


3.5  THE  OPERATIONAL  ADVANTAGES  OF  THE  IMAGERY  INTEROPERABILITY 

ARCHITECTURE 


3.5.1  INTEROPERABLE  IMAGE  SURFACE  STATION  (IISS)  OVERVIEW 


When  interoperability  is  achieved  among  all  reconnaissance/surveillance  and  exploitation 
systems,  the  development  of  the  Common  Ground  Station  (CGS)  becomes  not  just  feasible  but 
practical.  A  key  component  of  the  CGS  is  the  exploitation  or  image  system.  A  modular  image 
processing  system,  which  permits  technology  insertion  and  has  the  adaptability  necessary  for 
addressing  unique  user  requirements,  is  an  essential  element  for  achieving  an  interoperable  ground 
system.  For  the  first  time,  with  the  acceptance  of  the  IIA,  it  is  now  technically  and  operationally 
feasible  to  evolve  an  Interoperable  Image  Surface  Station  (IISS)  which  is  capable  of  receiving, 
processing,  and  disseminating  any  imagery  from  any  source.  The  IISS  is  a  viewing/exploitation 
system  that: 

V  Follows  the  Open  System  Architecture. 

V  Can  receive  and  process  any  image. 

V  Is  reconfigurable  to  meet  all  imagery  viewing  and  exploitation  needs. 

Because  the  IISS  follows  the  open  system  architecture  it  consists  of  common  and  non¬ 
common  components.  The  IISS  can  be  reconfigured  to  meet  any  image  viewing  or  exploitation 
requirement.  The  IISS  is  an  evolutionary  system  that  can  be  expanded  or  changed  to  meet  different 
imaging  requirements  and  different  levels  of  image  verification.  In  order  to  meet  these 
evolutionary  requirements,  the  IISS  must  be  developed  using  the  International  Standards 
Organization’s  Open  Systems  Interconnection  (OSI)  model.  The  OSI  model  establishes  a  set  of 
standards  for  network  protocols,  point-to-point  communication  protocols,  systems  environments, 
and  data  transfer  formats.  This  high  level  of  standardization  is  also  a  de  facto  standard  used  in 
international,  national,  DoD,  and  commercial  systems.  These  standards  allow  greater  extensibility 
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of  the  communications  resources  and  application  software,  and  scalability  of  system  hardware  and 
software.  They  also  result  in  reduced  maintenance  support  and  training  for  both  hardware  and 
software,  and  establish  a  more  consistent  user  interface  across  internal  and  external  systems.  The 
HSS  will  be  developed  using  C,  Ada,  and  other  HOLs  necessary  to  easily  construct  the  software 
modules. 


3.5.2  THE  nSS  OPEN  SYSTEM  ARCHITECTURE 


IISS  will  be  developed  in  accordance  with  the  standards  established  under  the  OSI  model 
which  provides  guidelines  for  standard  file  transfer  protocols  and  file  formats  for  most  data  types. 
These  standards  enable  vendors  to  read  the  data  contained  in  another  vendor’s  file.  This  allows 
multiple  independent  systems  to  be  easily  integrated  into  an  interoperable  system.  The  IISS 
environment  includes:  windowing,  data  base  queries,  graphics  processing,  imagery  processing, 
interoperating  system  communication,  Local  Area  Network(s)  (LANs),  and  operating  systems. 
The  IISS  transfer  formats  for  all  data  types  will  include  text,  graphic,  and  imagery  files. 
Throughout  the  IISS  system  environment,  data  integrity  will  be  maintained  and  provisions  will  be 
included  to  ensure  that  no  information  is  lost  or  that  the  quality  of  data  is  not  compromised. 
Exhibit  13  illustrates  the  basic  architecture  of  the  IISS. 


Exhibit  13 

Basic  Architecture  of  the  IISS 


The  IISS  will  be  designed  as  an  evolutionary  system  which  can  meet  new  functional 
requirements  and  incorporate  new  technology  and  advanced  imagery  processing  systems  as  they 
are  developed.  In  order  to  meet  this  system  challenge,  the  IISS  will  be  designed  to  provide 
interoperating  systems  support.  This  support  consists  of  establishing  the  appropriate  protocols, 
file  formats,  and  system  environment  standards  in  a  manner  that  will  promote  interoperability  and 
extensibility  without  impacting  the  unique,  internal  needs  of  each  specific  system.  The 
evolutionary  potential  of  the  IISS  is  illustrated  in  Exhibit  14. 
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Exhibit  14 

An  Example  of  the  Modular  ESS 
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The  IISS  open  system  architecture  allows  multiple  systems  to  be  integrated  into  a  single 
functional  component.  The  user  workstation,  which  is  the  device  used  for  viewing,  exploiting, 
and  reporting,  along  with  the  local  area  network  (LAN)  arc  the  basic  components  of  the  IISS  from 
which  other  configurations  can  evolve.  Both  of  these  systems  have  significant  growth  potential  to 
increase  the  functional  capabilities  of  the  IISS.  Other  systems  or  components  can  also  be 
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integrated  into  the  I1SS.  An  example  of  an  IISS  configured  to  meet  a  specific  operational  need  is 
illustrated  in  Exhibit  IS. 


Exhibit  15 

An  Example  of  an  OSS  Operational  Configuration 
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3.5.3  WORKSTATION 


The  IISS  workstation  is  the  primary  functional  system  that  interfaces  the  operator  with 
existing  and  evolutionary  IISS  capabilities.  Critical  in  the  design  of  the  IISS  is  the  system 
allocation  of  functions  on  either  the  workstation  or  onto  another  interoperating  system.  A 
workstation  is  generally  divided  into  the  following  functional  components:  a  display  device,  a 
man/machine  interface  control,  and  an  input  device. 


4.0  SUMMARY 


With  the  rising  demand  for  timely  high  quality  imagery  and  the  steady  decline  in  military 
budgets,  interoperability,  achieved  through  maximum  use  of  technically  sound,  cost  effective 
methods  is  critical  for  meeting  operational  requirements.  Interoperability  allows  any  ground 
system  to  receive,  process  and  disseminate  all  imagery.  When  imagery  interoperability  is  achieved 
any  ground  system  can  receive  the  necessary  and  appropriate  information  on: 

V  What  imagery  has  been  collected  and  when  it  was  collected. 
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V  What  imagery  is  planned  to  be  collected  and  when  it  will  be  collected. 

V  Where  and  when  a  collector  will  be  in  range  or  view  to  data  link  the  required  imagery 
directly  to  the  ground  station. 

V  How  imagery  that  has  been  collected  can  be  transmitted  to  the  ground  station  other  than 
by  directly  down  linking  the  imagery. 


4. 1  BENEFITS  OF  THE  IMAGERY  INTEROPERABILITY  ARCHITECTURE 


The  Imagery  Interoperability  Architecture  (IIA)  is  a  cost  effective,  flexible  means  for 
achieving  imagery  interoperability  among  the  digital  electronic  imagery  assets  of  the  United  States 
and  its  allies.  The  reconnaissance  program  will  gain  numerous  benefits  by  appropriately  applying 
the  HA  on  new  systems  as  well  as  existing  systems.  The  IIA: 


4.1.1  PROVIDES  INTEROPERABILITY  ACROSS  THE  RECONNAISSANCE  FORCE 
STRUCTURE 


First  and  foremost  the  IIA  provides  the  capability  to  allow  an  image  collected  by  one 
reconnaissance  system  to  support  the  needs  of  a  user  of  another  collection  system.  By  using  the 
IIA,  the  user  need  not  be  aware  of  how  his  specific  imagery  needs  are  met. 


4.1.2  T  TMITS  THE  PROLIFERATION  OF  UNIQUE/DEDICATED  SYSTEMS 


Through  the  implementation  of  the  IIA  standards  the  need  for  unique  and/or  dedicated 
systems  tends  to  disappear.  If  future  reconnaissance  systems  follow  the  architecture  then 
interoperability  is  assured. 


4. 1 .3  ENHANCES  COMBINED  OPERATIONAL  FLEXIBILITY 


The  IIA  allows  various  reconnaissance  systems  and  users'  systems  to  be  integrated  into 
different  configurations  to  meet  any  specific  operational  need.  This  attribute  of  the  IIA  is  critical 
for  meeting  today's  and  tomorrow's  military  demands.  Changes  in  milba  j  doctrine  will  occur 
and  the  military  must  be  ready  to  respond. 


4. 1 .4  REDUCES  DEVELOPMENT  COSTS 


The  basic  reason  for  the  establishment  by  the  International  Standard  Organization  of  the 
OSI  model  was  to  reduce  overall  system  development  costs  and  to  provide  a  more  competitive 
development  environment.  By  following  this  model  for  system  development  the  IIA  shares  the 
same  attributes  as  the  OSI  model.  Standards  allow  competitive  developers  to  propose  different 
system  and  technology  solutions  to  meet  the  same  need. 
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4. 1 .5  PROVIDES  COMMONALITY  IN  LOGISTICS  AND  TRAINING 


As  a  variety  of  systems  are  developed  that  address  similar  functions,  a  greater  degree  of 
commonality  in  both  logistic  support  and  training  is  ensured  when  each  system  is  implemented  to 
meet  the  appropriate  system  standards. 


4. 1 .6  MAXIMIZES  THE  BENEFIT  OF  OVERALL  IMAGERY  RECONNAISSANCE 
SYSTEMS  INVESTMENT 


When  an  imagery  reconnaissance  system  incorporates  the  IIA  it  inherits  a  flexibility  that 
allows  it  to  fulfill  the  requirements  for  which  it  was  developed,  while  also  achieving  the  capability 
to  expand  its  functionality  to  support  a  commander's  changing  operational  requirements.  The  IIA 
provides  the  interoperability  necessary  for  any  system  to  interface  with  and  disseminate 
information  to  any  surface  system  requiring  the  collected  imagery. 


4.2  CONCLUSION 


The  Imagery  Interoperability  Architecture  (IIA)  is  the  key  for  achieving  interoperability 
among  all  reconnaissance  assets  both  U.S.  and  with  those  of  our  allies.  Once  imagery 
interoperability  is  established  the  development  of  an  Interoperable  Image  Surface  Station  is 
attainable.  The  IIA  provides  the  information  and  standards  for  a  total  reconnaissance  force  to  get 
"the  right  image  to  the  right  user  at  the  right  time."  The  IISS  provides  the  system  architecture  to 
integrate  both  common  and  non-common  components  into  a  surface  system  that  can  receive  any 
image  at  any  time,  thus  meeting  the  military  imagery  needs  for  today  and  tomorrow. 

The  Image  Exploitation  Branch  of  Rome  Laboratory's  Intelligence  and  Reconnaissance 
Directorate  is  responsible  for  the  the  Imagery  Interoperability  Architecture.  The  point  of  contact  is: 
Mr.  Ronald  B.  Haynes,  RL/IRRE,  Griffiss  AFB,  New  York,  13441-5700. 


26 


Appendix  A 


List  of  Documents  Related  to  Imagery 
Interoperability  Architecture 


27 


APPENDIX  A 


1 


UST  OF  DOCUMENTS  RELATED  TO  IMAGERY  INTEROPERABILITY 

ARCHITECTURE 
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DOCUMENT 

Unmanned  Vehicles 

Defense  News 

18  February  1991 

Unclassified 
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APPENDIX  B 


POINTS  OF  CONTACT 


Program/ 

Standard 

Name 

Organization 

Telephone 

Joint  Services  Imagery 
Processing  System  (JSIPS) 

Mr.  Lawrence  Bush 

ESD/IC 

Hanscom  AFB,  MA 

617-271-8043 

Imagery  Interoperability 
Architecture  (IIA)  Program 

Mr.  Ronald  Haynes 

Rome  Lab/IRRE 

Griffiss  AFB,  NY  13441 

315-330-4592 

Common  Data  Link  (CDL) 

Lt  Col  C.  Osterheld 

SAF/DSPO 

Pentagon  RM  BD944 
Washington,  DC  20330 

202-694-2731 

MIL-STD-2179B 

Mr.  Borys  Umyn 

Naval  Ah’  Development 
Center  (NADC) 
Warminster,  PA 

215-441-2747 

STANAG  7023 

Mr.  Ronald  Haynes 

Rome  Lab/IRRE 

Griffiss  AFB,  NY  13441 

315-330-4592 

STANAG  7024 

Mr.  Ronald  Haynes 

Rome  Lab/IRRE 

Griffiss  AFB,  NY  13441 

315-330-4592 

Reconnaissance  Data 
Exchange  Standard  (RDES) 

Mr.  Ronald  Haynes 

Rome  Lab/IRRE 

Griffiss  AFB,  NY  13441 

315-330-4592 
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